Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@internal/config/config.go`:
- Around line 43-50: The Validate method of StorageConfig does not trim
whitespace from the Type and Bucket fields before validation, allowing values
with only whitespace to pass validation and fail later at runtime. At the
beginning of the Validate method, trim whitespace from both s.Type and s.Bucket
fields using strings.TrimSpace, then proceed with the existing validation logic.
This ensures that storage.type and storage.bucket values containing only spaces
are rejected immediately rather than deferring failure to runtime.

In `@internal/dumps/catalog.go`:
- Around line 152-156: The order of deletion operations in the delete method is
incorrect and risks leaving dangling catalog entries on partial failure.
Currently, the code deletes the dump file first using dumpKey(id) and then the
metadata using metaKey(id). Reverse the order of these two Delete calls so that
the metadata is deleted first using metaKey(id), then the dump file is deleted
using dumpKey(id). This ensures that if the second delete fails, the worst case
is an orphaned dump body rather than a catalog entry pointing to a deleted body.
- Around line 136-139: In the List method, the current error handling after
calling ReadMeta skips all errors indiscriminately using continue, which masks
backend failures and context cancellation errors. Instead, differentiate between
error types: only continue for corrupt entry errors that should be skipped by
the user later, but return immediately for system errors like context.Canceled
or other backend failures. Check the error type or message to determine if it
represents a corrupt user entry before deciding whether to continue or propagate
the error.

In `@internal/storage/local_test.go`:
- Around line 38-39: The os.ReadDir call on line 38 ignores the returned error
using underscore, which can mask setup failures and result in misleading
assertion messages when the directory is checked for cleanliness. Capture the
error returned by os.ReadDir instead of discarding it, then add explicit error
handling (typically using t.Fatal or t.Errorf in the test) to properly report if
the ReadDir operation fails before proceeding with the len(entries) != 0
assertion.

In `@internal/storage/local.go`:
- Around line 58-66: The Put method fails to guarantee durable writes as
declared in the interface because it only closes and renames the temporary file
without syncing data to disk. After writing to the temporary file (tmp), call
Sync on the file handle before closing it to ensure all file data is written to
disk. Additionally, after the os.Rename call that moves tmpName to its final
location p, open and sync the parent directory to ensure the metadata changes
from the rename operation are persisted, which will satisfy the durability
guarantee.
- Around line 62-63: The os.Rename call in the Store.Put method fails on Windows
when the destination file already exists, violating the overwrite contract
required by the interface. To fix this, implement a platform-safe atomic replace
strategy by first removing the destination file (using os.Remove on the path p)
before attempting os.Rename, or use a cross-platform helper function that
handles both Windows and Unix-like systems. This ensures that overwriting an
existing key works consistently across all platforms in the CI matrix, including
windows-latest.

In `@internal/storage/store.go`:
- Around line 18-23: The documentation for the ErrNotFound variable incorrectly
states that Get/Stat/Delete all return ErrNotFound when a key is absent, but
this contradicts the interface contract where Delete and Stat are defined as
non-errors for missing items. Update the documentation comment for ErrNotFound
to accurately reflect that only Get returns ErrNotFound for missing keys,
removing the incorrect references to Stat and Delete from the description.

In `@internal/storage/suite.go`:
- Around line 125-126: The io.ReadAll call at line 125 and the Stat call at line
140 are ignoring errors by using blank identifiers, which can mask real backend
failures in the suite tests. Capture the error return values from both
io.ReadAll and Stat operations, and add appropriate error assertions or checks
(such as asserting the error is nil or handling the error case) to ensure these
operations succeed before proceeding with the contract assertions. This will
prevent the tests from passing when there are actual backend failures.

In `@internal/tui/modals/restore.go`:
- Line 30: The call to d.Dumps.List() in the restore modal uses
context.Background() which creates an unbounded context that can block the TUI
indefinitely during remote storage operations (e.g., S3). Replace
context.Background() with a bounded context that has a timeout, or refactor the
NewRestore function to accept a context parameter from the caller and thread
that context through to the List() call. This ensures the storage I/O operation
is cancellable and won't hang the user interface.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@internal/storage/local.go`:
- Around line 88-91: The fallback in atomicRename is too broad: it removes dst
after any os.Rename failure, which can delete valid data on unrelated errors.
Update the rename retry logic in atomicRename to only attempt removing dst when
the failure specifically indicates the destination already exists or cannot be
replaced, and otherwise return the original error immediately. Keep the
retry/remove behavior guarded by the existing os.Rename and os.Remove flow so
the overwrite path is only used for the intended case.